Alde ADA 5 #1/ADA CD-ROM - Alde Publishing.iso/tools/prp.rpt

Text File | 1988-05-03 | 11.1 KB | 186 lines

           Ambient RF Propagation for Communications in Ada
                      Contract N66001-85-C-0042
                              Final Report
                             1 October 1985

                            IWG Corporation
         975 Hornblend St., Suite C, San Diego, CA 92109


OVERVIEW
     The conversion of the SIMSTAR ambient RF propagation routines to
Ada has been completed.  The Source code (CDRL A001), the executable
code (CDRL A005), and the users manual (CDRL A003) resident on the NOSC
TECR in directory [CONTR41.PROPLINK].  This final report contains
additional information concerning PROPLINK and a discussion of the
problems encountered and lessons learned during this project (CDRL
A002).  New features should be considered for future additions.

PRODUCT DELIVERY
     Proplink is a stand-alone RF propagation prediction program which
allows easy use of the SIMSTAR RF propagation routines through an
interactive front-end processor.  It allows the user to describe a
complex network of links by node, receiver, and transmitter
descriptions.  The signal and noise at each receiver is calculated using
one of the five propagation modules: ELF, VLF, LF, MF/HF, and
VHF/UHF/SHF/EHF.   Detailed instructions are given in the user's manual
which can be found in the file PROPLINK.DOC in the directory [CONTR41].
World read access as been given for this file.  The User's manual
includes a sample PROPLINK session and a Package "Withing" Map.  The
source code (.TXT) and executable code (.SYM) can be found in 101 files
in directory [CONTR41.PROPLINK].  The code has been compiled under
Telesoft Ada 1.5 and will execute with the command TRUN PROPLINK.  Also
included on the directory are four seasons of Noise data and several
sample data sets: ELFTEST.DAT, VLFTEST.DAT, LFTESTD.DAT, LFTESTN.DAT,
HFTEST.DAT, and VHFTEST.DAT.  These test data sets have been run on both
the FORTRAN version and this Ada version of PROPLINK to verify the
accuracy of the Ada version.  It should be noted that PROPLINK includes
several useful packages in addition to the propagation routines.
ENTITYUTI provides useful utilities for parsing an input string, and
storing alphanumerics as integers.  COMPLEX is a complex number package.
IOANDFILE contains some generic file handling utilities.  NODELOC does
great circle geometric interpolation and extrapolation.  It is hoped
that these routines can be used in other Ada software.
     The product is competitive with current FORTRAN simulation
capabilities.  In view of the current state of Ada, the product may be
years in advance of the user community.  Once Ada embedded systems
software becomes more prevalent, PROPLINK should realize its potential
in the Ada community.  In particular, it could be used to design, test
and simulate any system performance where hardware communications is an
issue with the potential for dramatic cost savings.

PROBLEMS ENCOUNTERED AND LESSONS LEARNED.
     At the outset of this project, we knew little Ada and had no
experience with an Ada compiler.  The problems we had and their
solutions should be of interest to future users.
     The greatest difficulties were related to the currently available
Telesoft compilers 1.5 and 2.1.  We started out with 2.1 assuming that
the newer version would be better for program development.  One NOSC
employee said that he always uses 2.1 now that it was available.  After
a week of extremely long compilation times (over an hour of CPU for 1000
lines of code) we turned to 1.5.  When Colonel Whitaker heard about our
switch to 1.5, he said that he wasn't surprised since no one has ever
attempted program development on 2.1.  It would have been nice to know
that earlier.
     But even 1.5 was slower than we had ever imagined.  This is largely
due to the heavy usage of the NOSC TECR.  At night, the compilation
times are not unreasonable.  Every attempt was made to compile at night,
although a reoccuring back end error precluded reliable use of batch
compilation.  Therefore, some daytime compilation could not be avoided.
During the final day of the project (the last full compilation) the
slowing of the computer drew the operator's attention.  Rather than
simply sending me a message to refrain from further compilation, she
just reduced the account's priority.  Fortunately, this blow took place
at the end of the project.  Future users should be warned that night
work is required and that day compilations should be held to an absolute
minimum lest you raise the operator's wrath.
     Another factor in the compilation time was the size of the
packages.  Many of them are over 1000 lines long.  The packages were
designed to group the subprograms logically by function.
Unfortunately, they were large.  Perhaps future users might consider
smaller packages to start with the intention of repackaging at the end
once compiler errors are fixed.  The time saved during compilation
would more than make up for the time it would take to repackage,
     Some major deficiencies in the 1.5 facility affected the progress
of the project.  First, the lack of a Mathlib was caused some delay
before one was located through Bruno Witti at NOSC.  He had recieved it
from Colonel Whitaker some time earlier.  The availability of that
package (and other utilities) should be made clear to future uses at the
outset, not when they need them.  The mathlib did not include the
complex number functions which are available in FORTRAN.  Therefore it
was necessary to write and test a complex number package.  It is hoped
that this package will find its way into an Ada library so that other
users can benefit from it.
     Second, the lack of a symbolic debugger was a great hindrance
during the final debugging stage.  Early on (January) we were told that
the TECR would have the DEC Ada compiler, which has a debugger,
available as soon as they went to VMS 4.2.  The estimated date for this
was said to be May at the latest.  As of the writing of this final
report, the TECR is still under 3.7 and no debugger is available.
Therefore, the archaic methodology of inserting Put statements into the
code and recompiling the package was used to clean PROPLINK.  It was
found that this technique was at least five times slower than it took to
check the same variables with the FORTRAN debugger.  It is hoped that
future users will get the benefits of an Ada debugger.
     Finally, a library utility would be helpful.  The fact that the
final directory has 101 files in it is evidence enough of this need.
     Turning to the conversion process, the serial approach used in this
project had benefits and drawbacks.  In this approach, one person did a
quick and dirty conversion from FORTRAN to Ada and the other
concentrated on compiling, debugging, cleaning, refining and, basically,
making it work. The primary advantage to this approach was that each
person got very good at their task.  In both cases a two or three fold
improvement in effiency was seen.  The only disadvantage was a disparity
in the relative hours that each job took.  While the initial conversion
took 10% longer than originally estimated, the cleaning task took almost
30% longer than expected largely due to the problems described above.
     Qualitatively, the serial approach impacted the final result in
that some Ada features were not used to their full advantage.  By
converting the FORTRAN line by line to Ada, we missed the chance to make
some sweeping changes to the way data was handled in the program.  In
particular, better use of record types could have been employed if they
had been designed prior to any conversion. In future projects, I would
recommend that the programmers study the variables to determine whether
advanced Ada types could be employed.
     The FORTRAN version of PROPLINK is not well structure at the
subroutine level; "spaghetti code" abounds.  There is heavy reliance on
GOTOs.  At the outset, it was thought that this would be a major problem
for conversion.  In fact, while difficult at times, it did not cause the
errors we had expected.  Therefore, future users are encouraged to
replace as much "spaghetti code" as possible and strive for "structured
programs".
     The most difficult aspect of the conversion was the replacement of
FORTRAN common blocks with several packages which are "withed" by many
other packages.  A major effort was made to reduce the number of
variables that were passed between subprograms are parameters.  The
problems occurred because the original FORTRAN used the same name for
different variables, different names for the same variables, and the
same name for the same variable in different units (e.g. FREQ is used
for hertz, kilohertz, megahertz, etc.).  Other problems included
incorrectly determining the proper mode of a formal parameter and
redeclaring a variable inside a procedure which was declared in a withed
package.  The result in both cases was the called procedure did not have
the proper value for the variable.  Perhaps the most bizarre problem of
this kind involved a FORTRAN subroutine which dimensioned an array but
did not initialize it.  In the Ada version, the array was declared
inside the procedure.  In fact, with each call of the FORTRAN
subroutine, the previous values were retained; the Ada declaration
effectively zeroed the array with each call.  The problem was solved by
moving the Ada declaration to the top of the package body.  Once
compiled, the majority of the remaining bugs were due to problems with
passing data between packages and subprograms.  Future users should be
cautious with passed data via calling parameters or withed packages.
     Overall, the project was very worthwhile, particularly in that it
resulted in an Ada capability at a small business that would not have
been achieved by any other means.  The advice, assistance, and
cooperation of the program managers and NOSC personnel was invaluable to
the success of this project and is greatly appreciated.

FUTURE EFFORTS
     Concurrent with this conversion, several additions and
modifications have been made to the FORTRAN version of PROPLINK.  Its
increasing use as a companion tool with SIMSTAR has brought out the need
for several new features.  These include:

1)  Increased flexiblity and user-friendliness of the front-end,
2)  Output of signal-to-noise ratios and the ability to define a
    threshold S/N.
3)  Knife-edge propagation for VHF
4)  Tropospheric propagation of VHF
5)  Meteor Burst propagation
6)  Laser links

     Some of these have already been included in the FORTRAN version;
all can be included into the new Ada version.  As Ada users of Proplink
expand, these new features will be very useful.  The conversion of
SIMSTAR to Ada is a major effort which requires a complete re-design to
correct the many existing deficiencies of the FORTRAN and to take
advantage of Ada's advanced capabilities.

ec. Whitaker, Courtwright, Loper, Schill
cc. Gratt, Becker, Perry, Conrad